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INTRODUCTION 


This document defines the basic components of a Network Standard Data 
Specification (NSDS) syntax. A NSDS is intended to provide a 
Mechanism for Specifying all the attributes of a collection of pits. 


The definition of a complete NSDS syntax is expected to require an 
extended effort. Therefore the initial scope of this document has 
been constrained to provide only a basic syntactic environment, 


In order to demonstrate a specific use for the NSDS, this document 
also provides the complete syntax for specifying the PATHNAME 
attributes of a collection of bits, to the level of a file, Addition 
of new subparameters should not be difficult. 


In this context, "pathname" refers to that information which 
Specifies the LOCATION of a collection of bits. 


The pathname syntax is essentially the same as that proposed in 
RFC 615 (NIC =~ 21531,). Modifications were made in order to 
allow for graceful addition of other file attributes and to 
optimize use by humans and by processes, 


I Would like to thank Jon Postel, Jerry Popek, Vint Cerf, Jim White, 
Charlie Kline, Buz Owen, Ken Pogran, Jerry Burenfiel and Tom Boynton 
for their suggestions. 
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HUMAN AND MACHINE FACTORS 


Since computers tend to prefer more highly structured environments 
than do humans, aspects of the NSDS syntax are permitted to be 
different for computers than they are for humans. Specifically: 


For computers (highly-structured mode), keyword fields are fixed 
length and the Variable-length data subfields are prefaced by a 
byte count, Additionally in highly structured mode, the possible 
contents of data subfields may te more constrained than for the 
semi-structured mode. 


For humans (semi-structured mode), keyword subfields are variable 
length and data suofields are surrounded by delimeter characters, 
A keyword must be long enough to distinguish it from other 
keywords, That is, partial-name specification is permitted. 


STRUCTURE OF THE GENERAL SYNTACTIC ENVIRONMENT 
Overview: 


A NSDS is prefaced by one or two percent signs, followed by a set 
of fields subject to context-free interpretation, and terminated 
With a Space, Pathname fields precede any other file attribute 
Specifications. 


The BNF: 
<NSDS> 33s <flag> <path> <othersturf> <sp> 
<flag> i= A / %4 
<path> 2:3 pathname fields, as described below, 


<otherstuff> :3s fields for specifying data storage and access 
Characteristics, to be defined later, 


<sp> 22 space. 
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Comments: 


The <flag> indicates escape-to-NSDS-syntax. One percent sign 
indicates semi-structured syntax, two indicate that 
highly~structured syntax is being used. 


Only <flag> must be considered in relation to any host's 
current syntax. It is not currently known to conflict with any 
host's syntax. 
Exclamation mark (1!) is the only other character that seems 
permissible (on the assumption that the character should be 
a graphic). Its use would cause minor problems at Multics; 
but more importantly as a graphic, it is too similar to the 
numeral "1". 
The basic (highest-level) syntax for individual <path> and 
<otherstuff> tields is the same, as defined below. The remaining 


lower-level syntax (including permissible keywords and data 
Subfield contents) for <otherstuff> fields is left for later. 


BASIO UNITS OF SUBSTRUCTURE 
Overview: 


A seminstructured field begins with a varying-length descriptor. 
The descriptor is followed by a varying~length data subfield, 
Which is surrounded by delimeter characters, 

Highly=structured fields have fixed-length descriptors, followed 
by a data byte-count, followed by the data. 


i 


BNF for individual fields: 


‘<field ¿s= <machine> / <human> 
<machine> r= <stru-field> / <stru-field> <machine> 
<stru-field> :s <stru-key> <count> <data> 


<struekey> 222 echaracter field definition keyword; see 
below. 
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<count> 225 oneebyte binary count of number of bytes of 

<data>,. 505 
‘<human> s:= Chefield> / <hefield> <human>d 506 
<nefielda> 33 <hekey> <h-rest> 507 
<h-key> ::= variable-length field definition keyword; gee 

below, 506 
<herest> i:s <ledelim> <data> <r-delim> 

/ lwdelim> <data> <r=delim> <h-rest> 509 
<l-aelim> 285 any non=alphabetic printable character that is 


not in the succeeding <data> subfield and that 
is acceptable to the object site. For visual 
aesthetics and to facilitate human parsing, 
anytime <i-delim> is a left-bracket character 
(<, fs (, “), <r-delim> must be the 
complementary right-bracket character (>, J» lə 


PE 5010 
<r-delim> :3= either 1) the same character aa <l-delim> or 2) 
if the <l-delim> ee is a leftebracket 
Character (<, /, (s ~) then its complementary 
right-bracket (>; Js s |) o 5bl1 
‘<data> 235 any sequence of characters acceptable to the 
object site. This is the actual data subfield 
with the file, directory, device (or whatever) 
attribute value. 5012 
Elaboration? 5e 


Case is irrelevant to the syntax, though some sites will care 
about case in <data> subfields. 5al 


The key (<stru~key> or <h-key>) indicates what part of the NSDS 
the next <data> Subfield refers to, 5c2 


<R-delim> and <l-delim> are used to delimit the beginning and end 
‘Of the <data> subfield, 5c3 


<Fielas> for pathnames ARE order dependent, but defaulted ones may 
be omitted. The order. is as indicated for <key>s, below. That 
is, Network, Host, e+. Siteparm. 5ch 
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Keywords are used, even though pathname attributes are ordered, 
to facilitate the addition of new fields and to be consistent 
with the syntax for <otherstuff> fields which are expected to 
be unordered, 


<Field>s or <herest> subfields may be repeated, as permitted by 
‘the object site, A series of <h-rest> subfields, without any 
¢hekey> subfields is interpreted as a series of <hefield>s with 
identical <key>s. 


Also, note that sinee the syntax does not constrain the 
contents of <data> subfields, compound names within a single 
<data> subfield are allowed. Tne delimeter used to separate 
names Within a <data> subfield must be different from 
<l-delim>/<r-delim> and the same as that used at the object 
site, since that is the only site which will be able to 
interpret the <data> subfield. 


The validity of any combiniation of <field>s is entirely 
Siteedependent. For example, if a site will accept it, an NSDS 
With a Host field, and nothing more, may be permissible, 


The validity of <data> subfields' contents is generally 
site-dependent. Some exceptions are noted below. 


PATHNAME ATTRIBUTES AND VALUES 


The baSic Syntax does not need to be altered, to create the ability 
to specify pathnames, Only <key> values need to be defined. 


Definition of Fathname <key>s: 


The keyword for semi-structured mode is given first, followed by 
‘the keyword for highly-structured mode, if different. For 
Aighly=structured mode, Keywords that are less than four 
‘Characters should be padded with blanks at the right. 


Semi Highly Meaning 

NETWORK NET Reference to the network (e+g+, ARPA) 
connected te the HOST that contains or wili 
contain the collection of bits, 

HOST Reference to host machine that contains or 
will contain the collection of bits, Also see 
section on "Numbers". 


‘PERIPHERAL PERI Peripheral device being referred to. 
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The volume (e.g, specific tape reel or disk 
pack) associated with the named peripheral 
device, 


Name of directory which contains a pointer to 
the entity (directory or filename) specified 
in the following <field>. 


Basic name of the file (data set). 


Optional modifier to filename. (Tenex calls 
it the Extension.) 


Optional third part to basic filename. 
Usually used to distinguish updated files. 
The <data> subfield will usually contain a 
number. 


A parameter, such aS an access specification 
or account number, peculiar to the object 
site. The contents of the <data> subfield 
must serve to identify what Siteparm is 
involved, Each site will be responsible for 
defining the syntax of Siteparm <data> 
subfields it Will accept. Note that the 
SITEPARM field allows specification of other 


than pathname data (€.ga, access and account 


number). 


Some reserved PERIPHERAL <data>s$ 


The alternate forms are merely for typing convenience and are not 
related to the semi/highly structure modes, 


DISK or DSK: 


ONLINE or ONL: 


TAPE or TAP: 


‘TAPET or TP73 


TAPES or TP9: 


DECTAPE or DEC: 


Immediate, direct-access secondary 
storage. 


Whatever immediately-accessible 
(measured in fractions of a second) 
storage the user accesses by default; 
usually disk.. 

Industry=compatible magnetic tape. 
7-Track industry compatible tape. 
9-Track industry compatible tape. 


DEC Tape. 


[5] 


6b6 


6b 


6b6 


609 


6b10 


6b11 


éc 


6cl 


6C2 


6¢3 
6Ch 
6cs 
-6C6 


6c7 


- NWGF/RFC# 645 DHU 26=JUN-7h 13:43 30899 
Network Standard Data Specification Syntax [6] 


OFFLINE or OFF: Any tertiary storage; usually tape, 
though "devices" like the Datacomputer 
are permissible. The user should 
expect to wait minutes or hours before 


being able to access OFFLINE files, 6c6 
LINE©PRINTER or LPT: Any available line-printer. 6C9 
‘DOCUMENT¢PRINTER or DOC: Upper/lower case line printer, 
preferably with 8 1/2" X 11" unlined 
paper. 6c10 
PAPER¢TAPE*READER or PTR: Paper tape reader. écll 
PAPER¢TAPESPUNCH or PTP; Paper tape punch. 6cl2 
CARD©PUNCH or PUN: Standard 60-column card punch. 6c13 
CARD©READER or RDR: Standard 6O-column card reader, 6cly 
OPERATOR or OPR: System Operator's console. 6cl5 
CONSULTANT or CONS On=line consultant, 6c16 
DEFAULTS FOR PATHNAME <DATA> SUBFIELDS: 6a 


Often, the appropriate default will be the last-used value. 
However, defaults will generally be context dependent. 
Consequently, the following defaults are offered only as 


guidelines? óai 
Networks ARPA. 6d2 
Host: The host interpreting the NSDS. 6a3 
‘Peripheral; ONLINE (DISK), | 6ah 
volumeeid: Catalogued system space. 6d5 
Directory: The user's current "working" directory, usually set 

by the logon process. , 6d6 
Filename: None. 6a7 
Type: None. 66 


Siteparn: None. 6a9 
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NUMBERS 


The following scheme is recommended for specifying numbers in 
<hefield> data subfields: 


A sequence of numeric characters, optionally followed by a 
character indicating the radix. The default radix is ten. "H" 
indicates hexadecimal; "0" (oh) indicates octal; "B" indicates 
binary; and (gratuitously) "D" indicates decimal. l 


In <struefield> data subfields, the number should be pure binary, 
Therefore, reference to a host on the Arpanet would require one 8=-bit 
byte, 


GENERAL COMMENTS 


The syntax is intended to be adequate for all hosts, so any given 
portion of it may be inappropriate for any given host, 


A Site is expected to permit specifications in a given field iff 
‘that site already has a Way of accepting the same information, 


Having two modes of specification (highly= and semi-structured) 
may prove teo be unnecessary., They are defined here merely as a 
‘convenience for experimentation. 


I believe that modifications to the syntax will be graceful 
additions, rather than Wholesale redesign, and thus can be deferred 
for a while, Currently, any undefined attributes must be specified 
in a Siteparm field. . 


The first version of the syntax was a mix of Tenex and Multics 
conventions. That is: 


(Network) [Host] Peripheral: Directory>Filename,Type;Siteparm 


Though visually more attractive and generally quicker to type, it 
lacks extensibility. For example, adding version number as a 
Standard field would be difficult. 


It is asserted (conceded) that, as long as extensibility is kept as a 
design goal, no standardized /semi-structuredj syntax will be as 
pleasant to use as currently exists on some systems. 
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SOME SAMPLE PATHNAMES 


Pathnames in NSDS that occupy more than one line, below, do so only 
because they are too ara for a Single line. Bracketed numbers 
(e.z., <8>) indicate a single byte with the number as its decimal 
Value. Blanks (spaces) are indicated by <sp>. 


My message file at ISI (<DCROCKER>MESSAGE.TXT;P7700}) 3 


Semi-structured 
*A(ISI/ D<DCROCKERDF (MESSAGEDT (TXT) S/P77Q4K0K/<sp> 
Highly«structured 


SHHOST<K1><86>DIR<sp><8 >DCROCKERFILE<7 >MESSAGETYPE<3>TXTSITE<7>P 
770L0h<sp> 


ARPO61.LAD.DOCUMENT at UCLA=CCN,. (Note the use of multiple Directory 
fields): 
Semi-structured 
SH(65] DIR[ARPO61] [LAD] F[DOCUMENT] <sp> 
Highly=structured 
ARHOSTK1><65>DIR<sp><6>ARPOGIDIR<sp>< 3>LADFILE<8>DOCUMENT<ap> 


>udd>compNet>Map>Mail at MiteMultics, (Note that the initial NSDS 
Directory <data> subfield is empty, in keeping with Multics! method 
of starting at the top of its directory structure): 


Semi-structured 
ŽH(540)DI/JDI/uaa] [CompNet]D(Map)FIL(Mail)<sp> 


Highly=structured 


SPHOSTKL><URODIR<sp><O>DIR<sp><3>uddDIR<sp><7>CompNetDIR<sp><3> 
MapFILE<4>Mail<sp> 
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